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SYSTEMS AND METHODS FOR MULTI-LEVEL BUSINESS PROCESSING 

BACKGROUND 

Field of the Invention 

[0001] The present invention relates to systems and methods for multi-level business 

processing. More particularly, the present invention relates to automated systems and 
methods for receiving information associated with business offers, evaluating the 
information, and responding to the business offers. 
Background of the Invention 

[0002] A business may receive numerous solicitations from another party, such as 

another business, in order to form contracts, such as business-to-business ("B2B") 
contracts. Whenever such a solicitation is received from an offering business, the 
receiving business must typically then consider the solicitation and the specific terms of 
the contract to ascertain whether such a contract would be beneficial for the receiving 
business. Consideration of such soliciting offers is both time consuming and costly, 
partly because representatives of the receiving business have to spend time considering 
such solicitation contracts. Furthermore, if the receiving business receives a large 
quantity of such solicitation contracts, there is no efficient way to consider all of the 
contract offers in a timely manner other than to have a number of personnel consider all 
such contracts. Finally, the soliciting business may renege on the solicitation offer if a 
considerable time period elapses before the receiving party reacts to the contract. This 
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time delay and requirement for live personnel decreases efficiency and increases costs 
associated with B2B contracts. 
[0003] An example of a business that routinely receives solicitation offers is a 

reinsurance company. Such a company typically receives a number of solicitation offers 
from other businesses, which are usually insurance companies. Such offers relate to 
various general or specific matters for which the insurance companies desire the services 
of the reinsurance company. Because of the potentially high number of such solicitation 
offers and the large number of volatile variables that are involved within each offer, time 
is of the essence in considering and replying to such solicitation offers. Any lapse of 
time between when a solicitation offer is made by an insurance company and a decision 
is rendered by the reinsurance company may result in a revocation of the offer or a 
change in status of a variable in the offer that significantly affects the offer. Thus, it is to 
the advantage of the both the insurance company and the reinsurance company to 
consider any potential B2B contracts in a rapid manner while minimizing the costs of 
such consideration. 

SUMMARY OF THE INVENTION 
[0004] The present invention, as described in the exemplary embodiments presented 

herein, addresses the shortcomings of the efficiencies and inaccuracies that typically 
occur between two or more parties in developing a business contract. Such parties may 
include individuals, businesses, agencies or governments. The examples presented 
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throughout this disclosure are directed to interactions between a reinsurance company 
and its typical customer, an insurance company. However, this example is merely 
presented for simplicity and is not intended to be limiting of the present invention. 
[0005] In one exemplary embodiment of the present invention, a system is disclosed for 

transacting business between a solicitor and a business. The system includes a server 
used by a business. The server is accessible by a solicitor. A contract evaluator is 
housed on the server. As used herein, the term "server" can include a network of servers. 
The contract evaluator receives input data by the solicitor and determines at a first stage 
whether the input data is complete to receive further evaluation, and at a second stage 
whether the input data as a whole falls within one or more specific pathways of further 
data evaluation. 

[0006] In another exemplary embodiment of the present invention, a system is disclosed 

for transacting business between a solicitor and a business. The system includes a server 
used by a business. The server is accessible by a solicitor. The system further includes 
means for contract evaluation housed on the server. The means for evaluation receives 
input data by the solicitor and determines at a first stage whether the input data is 
complete to receive further evaluation, and at a second stage whether the input data as a 
whole falls within one or more specific pathways of further data evaluation. 

[0007] In yet another exemplary embodiment of the present invention, a method is 

disclosed for transacting business between a solicitor and a business. The method 
includes accessing a server by a solicitor. The server is used by the business. The 
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method further includes evaluating data that is input by the solicitor and determining at a 
first stage whether the input data is complete to receive further evaluation, and at a 
second stage whether the input data as a whole falls within one or more specific pathways 
of further data evaluation. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0008] Figure 1 is a schematic diagram showing an exemplary system of the invention. 

[0009] Figure 2 is a flowchart showing an exemplary process in accordance with a 

preferred embodiment of the invention. 
[0010] Figure 3 is a flow diagram showing an exemplary process of the invention as 

implemented in the reinsurance business context. 
[0011] Figure 4 shows a different embodiment of a triage system of the invention that 

may be configured or adapted for use in the reinsurance business or another business. 
[0012] Figure 5 shows an exemplary three-level triage system of the invention. 

[0013] Figures 6, 7, 8, 9, 10, and 1 1 are exemplary screenshots that can be used in the 

exemplary processes and systems described in Figures 1-5 above. 
[0014] Figures 12 and 13 show two portions of an exemplary screenshot that shows an 

exemplary manual counteroffer that can be provided by a system of the invention. 
[0015] Figure 14 shows an exemplary process through which a claim may be processed 

in a placement-negotiation-execution-acceptance (PNEA) model in a back office context. 
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[0016] Figure 1 5 shows how an exemplary triage process of the invention may be 

incorporated in a reinsurance business transaction in the PNEA model in a front office 
context. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
[0017] The systems and methods according to the present invention utilize a universal 

interface between a solicitor or customer and a business to facilitate potential business 
opportunities between two or more parties. The exemplary systems and methods 
presented herein decrease the time and labor associated with conventional offer- 
acceptance contract preparation, resulting in decreased costs and increased efficiency in 
transactions between an offeror (typically the solicitor) and an offeree (typically the 
business). 

[0018] Although exemplary embodiments described herein are made with reference to 

the reinsurance industry as an example, the invention is not limited to this type of 
business. Other types of businesses would benefit from the exemplary systems and 
methods described herein, and with some known adaptations or configurations to 
conform to the particular business. For example, any type of organization that may 
potentially receive a large number of solicitation offers for creating a contract may 
benefit from the systems and methods described herein, with expected modifications, 
apparent to one having skill in the art, to conform to the specific organization. 
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[0019] Figure 1 is a schematic diagram showing an exemplary system of the invention. 

System 100 of the invention includes server 140 and evaluator 150. Server 140 can 
include one server or a network of servers. Server 140 is associated with business 130. 
For example, server 140 can be owned, operated, or otherwise maintained by or on behalf 
of business 130. Server 140 is associated with evaluator 150. Evaluator 150 is 
associated with a processor that is configured to execute processes and methods in 
accordance with the present invention as described herein. 

[0020] Server 140 is accessible to one or more solicitors 1 10 over network 120. Firewall 

142 of server 140 is provided to prevent unauthorized access to server 140. The use of 
firewall 142 is well known in the art and it is therefore not described in detail herein. 

[0021] Solicitor 1 1 0 and business 1 30 can communicate with each other via network 1 20. 

Network 120 can be any known communications network. Preferably, Network 120 is 
the Internet. In the context of the reinsurance industry, solicitor 1 10 is an insurance 
company that sells insurance policies to insured parties. Business 130 is a reinsurer that 
deals with solicitor 1 10 in provision of reinsurance services associated with the insurance 
policies of solicitor 110. 

[0022] For example, when solicitor 110 (e.g., an insurance company) provides business 

130 with a request of offer that includes input data, the input data flows through 
application modules associated with server 140. For convenience, the process associated 
with the applications modules is hereinafter referred to as the 'triage" process. 
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[0023] The request is first validated technically to ensure that the input data provided by 

solicitor 1 10 fits the minimum data quality requirements. The data quality requirements 
can include, for example, correct syntax, each value of the input data is within a 
predefined (context-less) range, basic relationships between values in the request are 
correct (e.g., DATE1 is before DATE2); and so on. 

[0024] Next, modules/functions^associated with server 140 can concentrate on business 

validation rules. The business validation rules can include a multi-stage or multi-pass 
process. For example, a first triage-pass can be performed based on fully automated 
rules. At the minimum, ithe first triage-pass provides the knowledge to further route the 
request to either an automated path or to a path that involves intervention by a user 
associated with business 130. A more sophisticated first triage-pass can provide much 
more functionalities. For example, a more advanced first triage-pass can select one out of 
several paths. The paths can be either automatic or manual. 

[0025] The more advanced first triage-pass can also check against various plausibility 

rules, policy rules, and system-data rules. The more advanced first triage-pass can further 
return to solicitor 110 indicating that some values (or relationships) need to be confirmed. 
The more advanced first triage-pass can even request additional information from 
solicitor 1 10 based on newly categorization of the request. Thus, the evaluation of the 
requests against the rules are done before the user associated with business 130 is even 
aware of the request taking place, while ensuring that solicitor 1 10 is not asked to provide 
unnecessary information. 
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[0026] Then, if the request is deemed complex enough to warrant human intervention, 

the request is forwarded to the user associated business 130 who can apply non- 
automated decisions. For example, a second triage-pass or even a third or fourth triage- 
passes can be used to further process the request. It is noted that the whole triage process 
can be nested, i.e., a new triage pattern may be triggered at any step along the process. 

[0027] Figure 2 is a flowchart showing an exemplary process in accordance with a 

preferred embodiment of the invention. Exemplary process 200 depicted in Figure 2 
includes steps 202 through 216. It is noted, however, other embodiments of the invention 
can include fewer steps or more steps than those depicted in Figure 2. 

[0028] In step 202, solicitor 1 10 accesses server 140 associated with business 130. As 

described above, access can be performed via a number of known methods, including via 
network 120. As noted above, server 140 is preferably protected by firewall 142. 
Network 120 is preferably the Internet. Other networks may be used. For example, a 
virtual private network (VPN) or the like may be used in lieu of the Internet. One 
purpose for solicitor 1 10 to access server 140 is to make a business offer to business 130. 
Another purpose may be for solicitor 1 10 to request a payment from business 130. Still 
another purpose may be for business 1 30 to make an offer to solicitor 1 1 0. Therefore, the 
solicitation can be initiated by either party. 

[0029] In step 204, evaluator 1 50 receives information from solicitor 110. The 

information can be, for example, input data associated with a business offer. In this step, 
a number of methods may be used. For example, solicitor 1 10 can download to server 
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140 a file that contains the input data associated with the business offer. Preferably, 
however, a user interface associated with server 140 and evaluator 150 is used by 
solicitor 1 10 to provide the input data. Preferably, the user interface is interactive. 
Preferably, the user interface includes a voice recognition module. 

[0030] In step 206, evaluator 1 50 reviews the input data. If the input data contains errors, 

process 200 returns to step 204. ^Otherwise, process 200 goes to step 208. The errors can 
be technical in nature. For example, there may be typographically errors associated with 
the input data. Other teclinical errors may include, for example, a subsequent date of a 
chain of events is erroneously input by solicitor 1 10 to be earlier than an initial date of 
the chain of events. Other rules that can be used to detect these errors can include the use 
of a maximum value associated with each input data field so that if the input data field is 
populated with a value that exceeds the maximum value, an error is detected. It is noted 
that step 206 is fully automated, e.g., no human intervention is involved. It is further 
noted that server 140 and evaluator 150 can accommodate a large number of rules. For 
example, in an exemplary implementation of the invention in the reinsurance business, 
about 500 to 1,000 rules can be considered by evaluator 150 in step 206. 

[0031] In step 208, if no errors were detected in step 206, or all errors previously 

detected have been corrected, process 200 determines whether the input data is valid. A 
validity determination in step 208 queries whether it makes business sense for business 
130 to accept the offer provided by solicitor 110, For example, even though the business 
offer input by solicitor 110 contains no technical error in the input data, evaluator 150 
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determines whether there is any business value for business 130 to accept the offer from 
solicitor 110, If the input data is valid, as determined by evaluator 1 50 in step 208, 
process 200 goes to step 210. Otherwise, process 200 ends, and the business offer is 
effectively rejected. Preferably, however, process 200 can optionally return to step 204 
so that solicitor 1 10 is given another opportunity to provide additional information 
tending to make a business case so that business 130 would accept the offer. In that case, 
steps 206 and 208 are repeated after server 140 receives the additional information from 
solicitor 1 10 in step 204. 

[0032] In step 2 1 0, evaluator 2 1 0 determines whether a validated request (i.e., after step 

208) from solicitor 1 10 can be responded folly automatically (e.g., without human 
intervention on behalf of business 130). If so, process 200 goes to step 212. Otherwise, 
process 200 goes to step 214. In an exemplary step 210, as an example and not a 
limitation, if the total liability in monetary terms associated with the business offer from 
solicitor 1 10 is below a predetermined threshold, process 200 can go to step 212. On the 
other hand, if the liability exceeds the predetermined threshold, process 200 can go to 
step 214. 

[0033] In step 212, evaluator 150 responds to solicitor 110. Here, for example, evaluator 

150 can accept an offer, decline an offer, or propose a counteroffer without human 
intervention. 

[0034] In step 214, further evaluation is made by business 130. Here, human 

intervention can be involved. For example, a user of business 130 such as a contract 

10 



Attorney Docket No. SRE0004-US 



administrator can review the input data associated with the business offer and make a 
determination regarding how the offer received from solicitor 110 should be responded 
to. 

[0035] In step 216, based on a decision received from the contract administrator of 

business 130, server 140 responds to solicitor 1 10. The response can include one of an 
acceptance of the offer, a rejection of the offer, a counteroffer to the offer, or another 
response. 

[0036] Figure 3 is a flow' diagram showing an exemplary process of the invention as 

implemented in the reinsurance business context. In this context, solicitor 1 10 is an 
insurance company and business 130 is a reinsurance company. Preferably, there is a 
pre-existing relationship between solicitor 110 and business 130. For example, a treaty 
or another contractual relationship is already in place between solicitor 110 and business 
130. Process 300 includes two user-system interaction instances. First user-system 
interaction instance includes processes enclosed by environment 301 . Part of the second 
user-system interaction instance includes processes enclosed by environment 302. 

[0037] Exemplary process 300 can be implemented as a multi-level business process for 

the reinsurance business. In data entry stage 310, data is captured, typically from input of 
solicitor 110 (e.g., using a browser via network 120). Note that data may also be 
captured via an API or data-storage medium. However, in such cases, no "intelligence" 
is present on the requestor side, and the interaction that is possible is relatively limited 
when dealing with "normal" systems. 
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[0038] Preferably, significant information relates to the details of the proposed contract 

offer is provided by solicitor 1 10 in stage 310. The information preferably includes, for 
example, one or more of a name of solicitor 1 10, a reference number associated with the 
treaty between solicitor 1 1 0 and business 1 30, a description of the subject matter of the 
offer, an amount of the insurance policy associated with the offer, a term (e.g., duration) 
of the insurance policy, and the like. 

[0039] After stage 3 10 is completed, process 300 involves stage 320. Stage 320 is a 

technical validation stage. In stage 320, data associated with the offer is validated. If an 
error is found, process 300 returns from stage 320 to stage 310. In an exemplary 
implementation of the invention, validation rules associated with stage 320 can be 
defined in three validation levels: (1) syntax and format; (2) context-less range of value; 
and (3) context of data in relationship to other values within the request. 

[0040] These three validation levels fit two interesting practical properties. First, the 

validation levels can be checked at the UI (user interface) or top level, thus providing 
better usability. Second, the validation levels can be used as integrity rules at the DBMS 
(database management system) or bottom level, thus enabling savings without 
compromising or complicating the DBMS design. The DBMS enables users to perform 
different operations on data. For example, data can be retrieved, appended, edited, 
updated. In addition, the DBMS enables reports to be generated. Once validated, the 
next processes can perform clearer and much more efficient business-level validations! 
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[0041] Input data provided by solicitor 1 10 is then considered within an automated triage 

process of the invention. Two or more passes or phases (stages 330 and 340) are present 
within an exemplary triage system of the invention. For example, it would be beneficial 
for any potential solicitation offer to be quickly considered by the triage system, as an 
initial step for any submission to the reinsurance company. The triage system performs 
in the same manner without regard to the content of the data being submitted. After 
evaluation of the data that has been submitted to the triage system, the automated system 
then determines which process is chosen for this specific submission. 

[0042] An exemplary triage system of the invention may be workflow-based (e.g., 

process-oriented) so that it offers various complexities within the workflow-design. 
Thus, it has a selection mechanism in place, which selects the most appropriate 
workflow. In this way, the triage system promotes an efficient but still adequate 
processing of a submission. For example, every time a triage results in the involvement 
of a new person and/or role, that is a workflow. The workflow involves, for example, the 
decision of who should do what as next step (based on existing rules and data, and the 
outcome of previous step or steps) and the forwarding of such a request for action to that 
person/system. 

[0043] At stage 330, the first pass, the triage system checks the new data against various 

sets of automated rules. In an implementation in the reinsurance business, several 
categories/dimensions for such rules have been identified. 
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[0044] The first set of rules is known as Plausibility rules. One example of the 

Plausibility rules is twelve-month coverage for Fac Property (Facultative Property) in 
Europe or lower or higher than expected premium payment in back office premium 
payment process. 

[0045] The second set of rules is know as Global and Local rules. One example of the 

Global and Local rules is that Petro-chemical placements (G) must go through a special 
evaluation. Another example of the Global and Local rules is that placement with TSI 
(Total Sum Insured) greater than SFr. 300M must be double-approved in Germany (L). 
Another example of the Global and Local rules involves reinsurer related rules (e.g., the 
client has had too many claims and needs to be audited, or "name clearing"). 

[0046] The third set of rules is know as Application rules, which can be used when the 

rating engine for TPL (Third Party Liability) is not advanced enough to enable automatic 
rating. 

[0047] Each of these rules can be designated as Silent, Vocal, or Extension. Silent means 

that no feedback is given to the user. However, later or subsequent processes may be 
affected (e.g., when all BUCs (Business Use Cases) in a specific market behave 
differently from the default behavior). Vocal means that the user is informed, i.e., 
process 300 returns from business triage stage 330 to data entry stage 310. For example, 
the Plausibility rules can be used to ask the user whether an interpretation by the triage 
system was really the meaning intended by the user. Extension are Vocal rules that imply 
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that additional information is needed (i.e., process 300 returns from stage 340 to stage 
310), before the next step (from stage 340 to stage 344) is performed. 

[0048] Note that up to stage 330 no human expertise has been involved in process 300; 

and yet, at stage 330, the data provided is accurate, and the data reflects the wish of 
solicitor 110. The data, or at least the majority of the data, contains sufficient 
information required to complete the business transaction. 

[0049] For example, at stage 330 it may be asserted whether a new placement fits into a 

facility agreement (process 300 goes from stage 330 to facility path 332), or is a simple 
commodity risk (process 300 goes from stage 330 to commodity path 334), or requires an 
underwriter (UAV)'s intervention (from stage 330 to stage 340). And, if the 
underwriter's intervention is required and or additional data is needed, this data has also 
already been provided (during the loop from stage 330 stage 310). 

[0050] Note also that this triage pattern allows business 1 30 to define data-capturing 

forms adapted or configured to its specific needs. For example, whether the data is 
required for this particular instance (e.g., claims history for placement or images for 
claims) or whether the data is asked for this particular instance. If additional data is 
needed, the data can be defined as mandatory. 

[0051] When required, manual intervention (e.g., from stage 340 to non-standard 

intervention 342 and from stage 340 to non-standard extension intervention 344) can be 
used for further triage of processing paths (e.g., voluntary escalation, decision on which 
rating tool to use, and so on). Additional information may be requested from solicitor 
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1 10 also at this step (e.g., from stage 340 to stage 310), although it typically comes in an 
unstructured way (e.g., files, chat etc.), which is not on-line or an immediate response. 

[0052] Figure 4 shows a different embodiment of a triage system of the invention that 

may be configured or adapted for use in the reinsurance business or another business. 
System 400 shown in Figure 4 is a two-level system. 

[0053] Following data entry in step 402, at first phase triage error level 404 of triage 

process 410, basic and clear errors are considered within the input data. Such errors can 
include, but are not limited to, obvious errors in calculations or omissions of necessary 
and important contract details. For example, system 400 can generate a stage one error 
when percentage calculations result in a total greater than 100%. There are several types 
of such errors include, for example, omission of required data (e.g., Name of Risk), 
wrong values (e.g., % > 100), wrong format (e.g., 22.33.4 when a number is expected), 
wrong basic relationships (e.g., "Start" of contract is after "End" of contract). 

[0054] System 400 may be designed to proceed back to input step 402 if there are 

deficiencies or errors detected at this first triage stage. Optionally, system 400 may alert 
the user (e.g., solicitor 1 10) as to what is deficient or what the error may be that has 
prevented advancement of the program. In this manner, the user can concentrate on the 
areas of the data input that contain errors or need more information. System 400 may be 
designed to loop constantly until all errors are taken out or the user decides to interrupt 
the process. Thus, first level 404 checks basic values and its path is: forward (single 
option) if data entry is acceptable, and back to the solicitor if not. 
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[0055] After all the errors of the first level are corrected, system 400 proceeds to the 

second level, which is known as second phase triage validation level 406. Second level 
406 of system 400 relates to the goodness or validation of the data that has been input. 
Stated differently, when system 400 proceeds to this second stage, the data input does not 
contain any obvious errors or deficiencies, and thus is now evaluated from a business 
perspective. In principle, in this second level, the same concept is applied as the first 
level with the number and the complexity of checks being greater and more sophisticated. 
A loop-back to the user for additional data entry could exist but is not mandatory. 

[0056] In second level 406, the data is considered to fit within one of two or more 

mathematical models that have separate pathways. In the example shown in Figure 4, 
two separate pathways or Processes A and B are shown, each with its own unique 
process. Depending on the quality and actual substance of the data that has been input, a 
given pathway is chosen to proceed. 

[0057] The criteria for the selection of one path over the other is the essence of the rules. 

Each rule, or a combination of rules, may define a specific path. In the cases of second 
level 406, users (human) may apply their own decisions about the next path. In an 
exemplary reinsurance business implementation of the invention, these rules can be sub- 
categorized as plausibility, company policy, local policy, tool policy, context (data 
already existing in the system) implications. 

[0058] The two-level triage system described in Figure 4 is an example of a two-level 

business processing system according to the present invention. However, such a two- 
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level system is not limiting of the invention. Any number of levels may be implemented 
to increase the efficiency and efficacy of such an automated business processing system. 

[0059] Figure 5 shows an exemplary three-level triage system of the invention. Stages 

502, 504, 506 of system 500 are similar in scope and function with corresponding stages 
402, 404, and 406 described with respect to system 400 shown in Figure 4. However, 
system 500 include added levels^ 522 and 532 of complexity that begins after second level 
506. Here, system 500 determines which of two exemplary pathways (i.e., one of 
automatic pathway 520 and semi-automatic pathway 530) should be followed depending 
on the quality and substance of the data that was input. First pathway 520 leads to an 
automatic response by system 500. Such automatic response is triggered when the data 
that was input by the user fit within an acceptable range that is predetermined by system 
500. Such ranges may be changed at any time by the business that operates such a 
system to account for changing business and environmental conditions. 

[0060] When the data is considered as falling within the predetermined acceptable ranges 

of system 500 and the data as a whole fits within an acceptable mathematical formula set 
to be used for "automatic" responses, the cost of the contract is considered by system 
500. Rating/pricing engine 522, for example, can be used to consider the input variables 
as compared to rules that have been pre-established by the business. Variables such as 
complexity, pricing and others may be considered. Rating/pricing engine 522 may 
accumulate hundreds or thousands of rules that are to be followed for a given set of input 
data. 
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[0061] In the case of an insurance company contacting a reinsurance company to solicit 

business, the cost of the contract is the premium that the insurance company must pay the 
reinsurance company as the cost of the coverage contract. After determining the data that 
was input for risk factors, and coming up with an ideal range of acceptable premiums, 
system 500 then compares such acceptable range of premiums with the premium that was 
input by the user. System 500 can propose its own premium if solicitor 1 1 0 did not 
provide a premium. If the input premium falls within the acceptable range, then system 
500 can signify that a contract has been formed and that the deal is complete. If, 
however, the input premium falls outside of the range of acceptable premiums for the 
given set of risks as determined by the input data, or no premium data was given by the 
user, then system 500 can consider the business offer to have no business value for 
business 130, effectively rejecting the offer. Alternatively, system 500 can be configured 
to present a counteroffer premium to the user. Such counteroffer may be, for example, 
the median of the range of acceptable premiums that system 500 calculated based on the 
risk from the input data. Alternatively, counteroffers may be made any time the input 
premium is below a set acceptable value within the range of acceptable premium costs. 
For example, a counteroffer may always be made if the premium offer is below the 
median of the acceptable range. Other options are also possible. 

[0062] Once system 500 determines that a premium offer is acceptable or the 

counteroffer is accepted by the user, then the contract is complete and system 500 
terminates the program. Such automatic consideration and response by system 500 is 
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possible when the originally input data (not including the input cost of the contract) falls 
within acceptable ranges preset in the system, 
[0063] If, however, the originally input data (not including the cost of the contract) falls 

outside of the acceptable range for the input variables, system 500 may deem the data 
inappropriate to be considered in an automatic process. System 500 can then proceed to 
semi-automatic pathway 530. In semi-automatic pathway 530, third level triage 532 is 
encountered wherein manual intervention 502 is considered. Here, authorized personnel 
representing the business' consider the variables that have been input by the soliciting 
user. Such personnel may be, for example, an underwriter or accountant or other expert. 
If such variables as a whole are acceptable as a whole for the business, then the personnel 
may signify system 500 to agree to the conditions set forth by the user. Thus, the 
personnel overrides system 500 in terms of accepting conditions or sets of variables that 
fall outside of the predetermined acceptable range of data for system 500. If, however, 
the personnel determines that the set of variables input by the user is unacceptable or 
disadvantageous for the business, the offer can then be rejected. The personnel may also 
change some elements in the original offer and provide a counteroffer. In one 
embodiment of the present invention, system 500 makes it impossible for the personnel to 
present a counteroffer so as to prevent misuse of system 500. Alternatively, the 
personnel may be authorized to present a counteroffer if the personnel determine that 
such a counteroffer is indicative of the risk of the proposed contract. 
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[0064] Although the exemplary embodiments described above have been shown with two 

or three levels of triage, the present invention is not limited to such levels of triage. Any 
number of triage may be incorporated within the present invention to increase the level of 
complexity and sophistication of the system. 

[0065] Figures 6, 7, 8, 9, 10, and 1 1 are exemplary screenshots that can be used in the 

exemplary processes and systems described in Figures 1-5 above. Specific terminologies 
associated with the reinsurance business are used in screenshots 600, 700, 800, 900, 
1000, and 1 100 in these figures. Again, the invention is not limited to implementations 
and embodiments in the reinsurance business. 

[0066] Screenshot 600 shown in Figure 6 can be included as part of a user interface that 

can be used by a user (e.g., solicitor 1 10) to input data associated with a business offer. 
Preferably, screenshot 600 includes input fields that are configured to receive minimal 
requirements or basic information associated with the business offer. In exemplary 
screenshot 600, the input fields can be categorized or grouped to include, for example, 
"Business and Reinsurance Type," "General Risk Information," and "Reinsurance 
Details." 

[0067] In each category of group of input fields, one or more of the input fields can be 

designated as "mandatory" input, which means the user is reminded that an input must be 
provided in those input fields. As shown in screenshot 600, each mandatory input field is 
indicated by an asterisk. Mandatory input fields can include "Name of Risk," "Original 
Policy/Reference Number," "Main Industry Code/Occupancy," Sub-Category," 
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"Zip/Postal Code," "Location," 'Currency," "Inception of Reinsurance Cover/' 
"Expiration of Reinsurance Cover," "Sum Insured," "Deductible," "Peril Covered," 
"MPL in % of Sum Insured," and "Num. Locations." Note that pull down menus (see, 
e.g., "Main Industry Code/Occupancy" input field) can be used to facilitate data input and 
to reduce user error. 

[0068] Screenshot 700 shown in Figure 7 is an exemplary screenshot that can be 

displayed to solicitor 1 10 in the event that the input data did not pass validation or error 
detection as described above. Note that an "Error" indication can be included as part of 
screenshot 700 to alert solicitor 1 10 to specific input fields where the errors are found. 
For example, the error indication can be represented by an exclamation mark nested 
within an upside down triangle. As shown in screenshot 700, errors have been found in 
the "Inception of Reinsurance Cover" input field. The upside down triangle can be color 
coded, for example, the triangle can be presented on screenshot 700 with the color red. 

[0069] Screenshot 800 shown in Figure 8 is an exemplary screenshot that can be 

displayed to solicitor 1 10 in the event that the input data (basic information) has passed a 
first level or first phase validation, but additional or extended information may be 
required to pass a second level or a second phase. To the extent that any additional or 
extended information is required by evaluator 150, a "Warning" indication can be 
displayed on screenshot 800 to alert solicitor 1 10 to provide additional or extended 
information. For example, the warning indication can be represented by an exclamation 
mark nested within an upside up triangle. As shown in screenshot 800, additional 
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information is requested in the "Total Sum Insured" input field. The warning indication 
triangle can be color coded, for example, the triangle can be presented on screenshot 800 
with the color yellow. Note also that the error indication is also indicated next to an 
"Extended Information" button near the top of screenshot 800. 

[0070] Screenshot 900 shown in Figure 9 is an exemplary screenshot that can be 

displayed to solicitor 1 10 so that solicitor 1 10 can input non-standard risk information in 
new input fields. Solicitor 1 10 can arrive at screenshot 900, for example, if he pressed 
the "Extended Information" button shown in screenshot 800. As shown in screenshot 
900, exemplary input fields associated with non-standard risk information can include 
"Survey Report/Risk Information," "Loss History," "Insurance Conditions/Wordings," 
"Reinsurance Conditions," and "Others." In addition, a "Message" field can be provided 
to receive additional comments from solicitor 1 10. 

[0071] Screenshot 1000 shown in Figure 10 is an exemplary screenshot that can be 

displayed to solicitor 1 10 so that solicitor 1 10 can input additional or extended 
information in new input fields. As shown in screenshot 1000, exemplary input fields 
can include "Occupancy," "Deductible per Event " "Sublimit per Event," "Aggregate 
Deductible," "Annual Aggregate," and "Premium." Note that non-standard extended 
information shown in screenshot 900 of Figure 9 can also be included in screenshot 1000 
of Figure 10 as well. 

[0072] Screenshot 1 100 shown in Figure 1 1 indicate that the basic information and the 

extended information can be required from solicitor 1 10 in the first instance in another 
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embodiment of the invention. Screenshot 1 100 basically consolidate screenshot 600 and 
screenshot 1000. Solicitor 1 10 can toggle between screenshot 600 and screenshot 1000 
by pressing one of the "Basic Information" button and the "Extended Information*' 
button, respectively. 

[0073] Figures 12 and 13 show two portions of screenshot 1200 showing an exemplary 

manual counteroffer that can be provided by a system of the invention. As shown in 
screenshot 1200, information associated with an insurance policy involved in a 
reinsurance offer-acceptance transaction can include type of insurance (e.g., flood, 
earthquake), deductible, sublimit per event and annual aggregate, and other information 
as shown in screenshot 1200. 

[0074] The triage system and process of the invention can be used in a front office 

context or a back office context. 

[0075] In the back office context, Figure 14 shows an exemplary process through which 

an insurance claim may be processed in a placement-negotiation-execution-acceptance 
(PNEA) model. In this context, the claim submission associated with process 1400 may 
be considered to be an offer made by the insurer. An approval of the claim submission 
may be considered to be an acceptance of the offer. 

[0076] As shown in Figure 14, when a claim is notified by a client (an exemplary 

solicitor 1 10), the claim is directed to an exemplary system of the invention in the 
"Placement" portion of the PNEA model. Within the Placement portion of the PNEA 
model (upper left quadrant), the system performs claims triage versus client data. For 
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example, the system can perform (1) technical claim validation; (2) basic business error 
validation; and (3) automatic business triage. Following these three steps, the system 
enters into the Negotiation portion of the PNEA model (upper right quadrant) if more 
information is needed or further evaluation is required. Otherwise, the claim can be 
rejected or the process can bypass the Negotiation portion altogether and proceed directly 
to the Execution portion (lower right quadrant). 

[0077] During the Negotiation portion, the system performs formal and factual review 

versus data/intelligent business triage that can be unique to the reinsurance industry. 
Following this formal and factual review, one or more outcomes are possible. For 
example, a first possible outcome involves a rejection of the claim. A second possible 
outcome involves the identification of an existing no-payment claim, A third possible 
outcome involves the identification of an existing payment request. A fourth possible 
outcome involves the identification of a new payment request. A fifth possible outcome 
involves the identification of a new no-payment claim. 

[0078] During the performance of the formal and factual review, new input from the 

reinsurer can be validated. Then, an automatic business triage can be performed. 
Following the automatic business triage, claims history of certificate/treat can be 
checked, claim can be verified, coverage can be analyzed, and adequacy of reserves can 
be reviewed. In addition, a decision can be made to determine whether further processing 
is needed. 
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[0079] After the formal and factual review, if the claim is not to be further processed, the 

system informs a cedent/broker regarding the non-approval of the claim. The system can 
then wait for a response from the cedent/broker. The cedent/broker can accept the 
decision or provide additional information. 

[0080] If a claim referral is required after the formal and factual review, the system 

initiates the claim referral. The system then proceeds to the Execution portion of the 
PNEA model. 

[0081] The system can proceed directly to the Execution portion if the claim needs to be 

further processed but a ciaim referral is not required. 
[0082] In the Execution portion, the system processes the claim. Here, the system can 

complete registration into a back office system, book into technical accounting, and/or 

transfer to general ledger. 
[0083] Finally, in the Acceptance portion of the PNEA model (lower left quadrant), the 

client is notified of the final decision of the system. The client can then accept the 

decision or not. 

[0084] In the front office context, Figure 1 5 shows how an exemplary triage process of 

the invention may be incorporated in the processes associated with a reinsurance business 
transaction in the PNEA model. Placement workflow 1500, as shown in Fig. 15, includes 
numerous processes. Some of these processes can incorporate the triage process of the 
invention. 
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[0085] In the Placement Preparation quadrant, exemplary processes include "D: 

Placements select type," "D: Placements detail entry," "P: Save draft placement," "P: 
Package information-Placement," "C: Placements detail review," "F: Check placement 
rules," and "V: Validate Placements detail." Of these, at least processes "F: Check 
placement rules" and "V: Validate Placements detail" can include at least one aspect of 
the triage process of the invention as described above. 

[0086] In the Placement Negotiation quadrant, exemplary processes include "D: Get 

packaged information-Placement," "F: Check Business Rules," "D: Get automatic rate," 
"C: Submit response," "N: Select Office/Region/Division," "N: Select Available 
placements," "Applying Underwriting Judgement," "D: Commission and share to 
SwissRe," "D: Get automatic rate," "D: My Rate (override auto with own rate)," "U: 
Chat with client," "V: Validate Placements detail," "F: Escalation Required?(*)," and "C: 
Placements detail review." Of these, at least process "Applying Underwriting 
Judgement," "V: Validate Placements detail," and "F: Escalation Required?(*)" can 
include at least one aspect of the triage process of the invention as described above. 

[0087] In the Placement Performance quadrant, exemplary processes include "A: 

Commit to database" and "A: Generate offer." In the Placement Acceptance quadrant, 
exemplary processes include "N: Select Available placements," "C: Placements offer 
review," "C: Placements offer accept," "A: Update offer into Bound business," and "D: 
Perform other action on offer." One or more of these processes may incorporate an 
aspect of the triage process of the invention. 
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[0088] The systems and methods of the present invention are designed to be user-friendly 

and readily accessible to a customer with minimal manual intervention by a business 
utilizing such systems and/or methods. Thus, a non-limiting means of providing access 
to the systems and/or methods of the present invention is through the Internet. A solicitor 
may readily access the business triage process through the Internet at any time and from 
any place in the world that allows Internet access. Such access may either be provided 
through hardwire means or remotely. This increased flexibility and lack of restraint with 
respect to time and place to provide a tremendous benefit to the user. Likewise, such 
flexibility offered to the user provides the business with increased partner base who are 
attracted to such flexibility. 

[0089] Systems and processes according to the present invention also automate 

accounting processes that have typically required time-consuming and inefficient manual 
handling. Further, they also improve efficiencies in other transaction areas. Such other 
areas include, but are not limited to, data exchange between customer and company (e.g., 
reinsurer), validation and plausibility checks, confirmation about the status of a 
transaction and changes of status. Other areas may also receive benefits from the current 
invention. 

[0090] The exemplary systems and methods described above according to the present 

invention have many advantages. One such advantage is that the interaction between the 
offeror and the business is automated. This automation reduces the costs and errors 
associated with non-automated processes, such as, for example, person-to-person 
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communications. Furthermore, all transactions are electronically recorded, thus, reducing 
the potential for miscommunication between live parties. Also, the ability to always 
merge back to the basic flow creates better structured and cheaper systems. 
[0091] Another unique advantage of the systems and methods according to the present 

invention is their ability for rapid expansion. Although the present invention is presented 
with very specific examples of procedures that are most commonly encountered in the 
reinsurance business, the invention is not restricted to this type of business. Any business 
that could benefit from automating transactional encounters between the business and its 
potential business partners would benefit from the use of this invention. The parameters, 
options and paths shown in the exemplary embodiments of the figures could be 
programmed to account for the specific requirements and unique business options of any 
other business. 

[0092] Another advantage associated with the triage process of the invention is that 

structured information can be used for businesses to build front and back office systems. 
Systems that are built using the triage process of the invention are easier to be developed. 
Furthermore, these systems, once built and developed, are easier to maintain. 

[0093] In describing representative embodiments of the invention, the specification may 

have presented the method and/or process of the invention as a particular sequence of 
steps. However, to the extent that the method or process does not rely on the particular 
order of steps set forth herein, the method or process should not be limited to the 
particular sequence of steps described. As one of ordinary skill in the art would 
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appreciate, other sequences of steps may be possible. Therefore, the particular order of 
the steps set forth in the specification should not be construed as limitations on the 
claims. In addition, the claims directed to the method and/or process of the invention 
should not be limited to the performance of their steps in the order written, and one 
skilled in the art can readily appreciate that the sequences may be varied and still remain 
within the spirit and scope of the invention. 

The foregoing disclosure of the embodiments of the invention has been presented 
for purposes of illustration and description. It is not intended to be exhaustive or to limit 
the invention to the precise forms disclosed. Many variations and modifications of the 
embodiments described herein will be apparent to one of ordinary skill in the art in light 
of the above disclosure. The scope of the invention is to be defined only by the claims 
appended hereto, and by their equivalents. 
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